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ABSTRACT 

We present HORNET, a system that enables high-speed end-to-end 
anonymous channels by leveraging next-generation network archi¬ 
tectures. HORNET is designed as a low-latency onion routing sys¬ 
tem that operates at the network layer thus enabling a wide range 
of applications. Our system uses only symmetric cryptography 
for data forwarding yet requires no per-flow state on intermediate 
routers. This design enables HORNET routers implemented on off- 
the-shelf hardware to process anonymous traffic at over 93 Gb/s. 
HORNET is also highly scalable, adding minimal processing over¬ 
head per additional anonymous channel. 

Categories and Subject Descriptors 

C.2.0 [COMPUTER-COMMUNICATIONNETWORKS]: Gen¬ 
eral —Security and protection 

General Terms 

Security, Performance 

Keywords 

Anonymity; onion routing; network layer 

1. INTRODUCTION 

Recent revelations about global-scale pervasive surveillance (m 
programs have demonstrated that the privacy of Internet users 
worldwide is at risk. These revelations suggest massive amounts 
of private traffic, including web browsing activities, location infor¬ 
mation, and personal communications are being harvested in bulk 
by domestic and foreign intelligence agencies. 

To protect against these threats, several anonymity protocols, 
tools, and architectures have been proposed. Among the most 
secure schemes for anonymous communications are mix net¬ 
works (3T][39l|22l|23), which provide high-latency asynchronous 
messaging. Onion routing networks (most notably Tor 1261 1. offer 
a balance between security and performance, enabling low-latency 
anonymous communication suitable for typical Internet activities 
(e.g., web browsing, instant messaging, etc.). Tor is the system of 
choice for over 2 million daily users fT2l , but its design as an over¬ 
lay network suffers from performance and scalability issues. Tor’s 
design requires per-connection state to be maintained by interme¬ 
diate nodes, limiting the total number of concurrent anonymous 
connections that can take place simultaneously. 

The scalability and performance limitations of anonymous net¬ 
works have been partially addressed by building protocols into the 
network layer rather than implementing them as overlays. Among 
these high-performing schemes are LAP (33) and Dovetail (45), 


which offer network-level low-latency anonymous communication 
on next-generation network architectures. The high performance 
of both schemes, however, results in significantly degraded secu¬ 
rity guarantees; endpoints have little to no protection against ad¬ 
versaries that are not confined to a single network location, and 
payload protection relies on upper layer protocols which increases 
complexity. 

In this paper, we present HORNET (High-speed Onion Routing 
at the NETwork layer), a highly-scalable anonymity system that 
leverages next-generation Internet architecture design. HORNET 
offers payload protection by default, and can defend against at¬ 
tacks that exploit multiple network observation points. HORNET 
is designed to be highly efficient: it can use short paths offered by 
underlying network architectures, rather than the long paths due to 
global redirection; additionally, instead of keeping state at each re¬ 
lay, connection state (including, e.g., onion layer decryption keys) 
is carried within packet headers, allowing intermediate nodes to 
quickly forward traffic without per-packet state lookup. 

While this paper proposes and evaluates a concrete anonymity 
system, a secondary goal herein is to broadly re-think the design 
of low-latency anonymity systems by envisioning networks where 
anonymous communication is offered as an in-network service to 
all users. For example, what performance trade-offs exist between 
keeping anonymous connection state at relays and carrying state in 
packets? If routers perform anonymity-specific tasks, how can we 
ensure that these operations do not impact the processing of regular 
network traffic, especially in adversarial circumstances? And if the 
network architecture should provide some support for anonymous 
communication, what should that support be? Throughout the pa¬ 
per we consider these issues in the design of our own system, and 
provide intuition for the requirements of alternative network-level 
anonymity systems. 

Specifically, our contributions are the following: 

• We design and implement HORNET, an anonymity system 
that uses source-selected paths and shared keys between end¬ 
points and routers to support onion routing. Unlike other 
onion routing implementations, HORNET routers do not keep 
per-flow state or perform computationally expensive opera¬ 
tions for data forwarding, allowing the system to scale. 

• We analyze the security of HORNET, showing that it can 
defend against passive attacks, and certain types of active at¬ 
tacks. HORNET provides stronger security guarantees than 
existing network-level anonymity systems. 

• We evaluate the performance of HORNET, showing that its 
anonymous data processing speed is close to that of LAP and 
Dovetail (up to 93.5 Gb/s on a 120 Gb/s software router). 
This performance is comparable with that of today’s high- 
end commodity routers 0. 
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2. PROBLEM DEFINITION 

We aim to design a network-level anonymity system to frustrate 
adversaries with mass surveillance capabilities. Specifically, an ad¬ 
versary observing traffic traversing the network should be unable to 
link (at large scale) pairs of communicating hosts . This property is 
known as relationship anonymity f42l . 

We define sender anonymity as a communication scenario where 
anonymity is guaranteed for the source, but the destination’s loca¬ 
tion is public (e.g., web sites for The Guardian or Der Spiegel). 
We define sender-receiver anonymity as a scenario where the an¬ 
onymity guarantee is extended to the destination (e.g., a hidden 
service that wishes to conceal its location). Sender-receiver ano¬ 
nymity therefore offers protection for both ends, implying sender 
anonymity. Depending on users’ needs, HORNET can support ei¬ 
ther sender anonymity or sender-receiver anonymity. 

Since our scheme operates at the network layer, network location 
is the only identity feature we aim to conceal. Exposure of network 
location or user identity at upper layers (e.g., through TCP sessions, 
login credentials, or browser cookies) is out of scope for this work. 

2.1 Network Model 

We consider that provisioning anonymous communication be¬ 
tween end users is a principal task of the network infrastructure. 
The network’s anonymity-related infrastructures, primarily routers, 
assist end users in establishing temporary anonymous sessions for 
anonymous data transmission. 

We assume that the network layer is operated by a set of nodes. 
Each node cooperates with sources to establish anonymous ses¬ 
sions to the intended destinations, and processes anonymous traffic 
within the created sessions. We require that the routing state of a 
node allows it to determine only the next hop. In particular, the 
destination is only revealed to the last node and no others. This 
property can be satisfied by IP Segment Routing Go), Future Inter¬ 
net Architectures (FIAs) like NIRA (49) and SCION (HGH, or 
Pathlets t29l . In practice, our abstract notion of a node could corre¬ 
spond to different entities depending on the architecture on which 
HORNET is built. Eor instance, in NIRA and SCION, a node cor¬ 
responds to an Autonomous System (AS); in Pathlets, a node maps 
to a vnode. 

Path and certificate retrieval. A path is the combination of rout¬ 
ing state of all nodes between the source and the intended desti¬ 
nation. We assume the underlying network architecture provides a 
mechanism for a source to obtain such a path to a given destina¬ 
tion. Additionally, we assume that the same mechanism allows the 
source to fetch the public keys and certificate^ of on-path nodes. 
Note that the mechanism should be privacy-preserving: the source 
should not reveal its network location or intent to communicate 
with a destination by retrieving paths, public keys, and certificates. 
In Section ITTI we further discuss how to obtain required informa¬ 
tion anonymously in selected EIAs. While a general solution rep¬ 
resents an important avenue for future work, it remains outside of 
our present scope. 

Public key verification. We assume that end hosts and on-path 
nodes have public keys accessible and verifiable by all entities. End 
hosts can retrieve the public keys of other end hosts through an 
out-of-band channel (e.g., websites) and verify them following a 
scheme like HIP 11401 . in which the end hosts can publish hashes 
of their public keys as their service names. Public keys of on-path 
nodes are managed through a public-key infrastructure (PKI). Eor 

* Depending on the underlying PKI scheme, the source might need 
to fetch a chain of certificates leading to a trust anchor to verify 
each node’s public key. 


example, the source node can leverage Resource Public Key Infras¬ 
tructure (RPKI) 03 to verify the public keys of on-path nodes. 

2.2 Threat Model 

We consider an adversary attempting to conduct mass surveil¬ 
lance. Specifically, the adversary collects and maintains a list of 
“selectors” (e.g., targets’ network locations, or higher-level pro¬ 
tocol identifiers), which help the adversary trawl intercepted traf¬ 
fic and extract parts of it for more extensive targeted analysis i). 
An anonymity system should prevent an adversary from leveraging 
bulk communication access to select traffic that belongs to the tar¬ 
gets. Thus an adversary has to collect and analyze all traffic and 
cannot reliably select traffic specific to targets unless it has access 
to the physical links adjacent to the targets. 

We consider an adversary that is able to compromise a fraction 
of nodes on the path between a source and a destination. For sender 
anonymity, the adversary can also compromise the destination. For 
sender-receiver anonymity, the adversary can compromise at most 
one of the two end hosts. By compromising a node, the adversary 
learns all keys and settings, observes all traffic that traverses the 
compromised node, and is able to control how the nodes behave 
including redirecting traffic, fabricating, replaying, and modifying 
packets. 

However, we do not aim to prevent targeted de-anonymization 
attacks where an adversary invests a significant amount of resources 
on a single or a small set of victims. Like other low-latency schemes, 
we cannot solve targeted confirmation attacks based on the analy¬ 
sis of flow dynamics dUllslIlD. Defending against such attacks 
using dynamic link padding 1481 would be no more difficult than in 
onion routing, although equally expensive. We defer the discussion 
and analysis of such measures to future work. 

2.3 Desired Properties 

HORNET is designed to achieve the following anonymity and 
security properties: 

1. Path information integrity and secrecy. An adversary can¬ 
not modify a packet header to alter a network path without 
detection. The adversary should not learn forwarding infor¬ 
mation of uncompromised nodes, node’s positions, or the to¬ 
tal number of hops on a path. 

2. No packet correlation. An adversary who can eavesdrop 
on multiple links in the network cannot correlate packets on 
those links by observing the bit patterns in the headers or 
payloads. This should hold regardless of whether the ob¬ 
served traffic corresponds to the same packet (at different 
points on the network), or corresponds to different packets 
from a single session. 

3. No session linkage. An adversary cannot link packets from 
different sessions, even between the same source and desti¬ 
nation. 

4. Payload secrecy and end-to-end integrity. Without com¬ 
promising end hosts, an adversary cannot learn any informa¬ 
tion from the data payload except for its length and timing 
among sequences of packets. 

3. HORNET OVERVIEW 

The basic design objectives for HORNET are scalability and effi¬ 
ciency. To enable Internet-scale anonymous communication, HOR¬ 
NET intermediate nodes must avoid keeping per-session state (e.g., 
cryptographic keys and routing information). Instead, session state 
is offloaded to end hosts, who then embed this state into packets 
such that each intermediate node can extract its own state as part of 
the packet forwarding process. 
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Offloading the per-session state presents two challenges. First, 
nodes need to prevent their offloaded state from leaking informa¬ 
tion (e.g., the session’s cryptographic keys). To address this, each 
HORNET node maintains a local secret to encrypt the offloaded 
per-session state. We call this encrypted state a Forwarding Seg¬ 
ment (FS). The FS allows its creating node to dynamically retrieve 
the embedded information (i.e., next hop, shared key, session expi¬ 
ration time), while hiding this information from unauthorized third 
parties. 

The second challenge in offloading the per-session state is to 
combine this state (i.e., the FSes) in a packet in such a way that each 
node is able to retrieve its own FS, but no information is leaked 
about the network location of the end hosts, the path length, or a 
specific node’s position on the path. Learning any of this informa¬ 
tion could assist in de-anonymization attacks (see Section IJifit . To 
address this challenge, the source constructs an anonymous header 
(AHDR) by combining multiple FSes, and prepends this header to 
each packet in the session. An AHDR grants each node on the 
path access to the FS it created, without divulging any informa¬ 
tion about the path except for a node’s previous and next nodes 
(see Section l4.4.1b . 

For efficient packet processing, each HORNET node performs 
one Diffie-Hellman (DH) key exchange operation once per session 
during setup. Eor all data packets within the session, HORNET 
nodes use only symmetric cryptography to retrieve their state, pro¬ 
cess the AHDR and onion-decrypt (or encrypt) the payload. To re¬ 
duce setup delay, HORNET uses only two setup packets within a 
single round trip between the source and the destination. Therefore, 
session setup only incurs 0{n) propagation delay in comparison to 
0(n^) by the telescopic setup method used in Tor (where n is the 
number of anonymity nodes traversed on the path). While for Tor 
the default value of n is 3, for HORNET n might be as large as 
14 (4.1 in the average case, and less or equal to 7 in over 99% of 
cases (3), which emphasizes the need to optimize setup propaga¬ 
tion delay. 

3.1 Sender Anonymity 

Anonymous sessions between a source and a destination require 
the source to establish state between itself and every node on the 
path. The state will be carried in subsequent data packets, enabling 
intermediate nodes to retrieve their corresponding state and forward 
the packet to the next hop. We now describe how the state is col¬ 
lected without compromising the sender’s anonymity, and how this 
state is used to forward data packets. 

Setup phase. To establish an anonymous session between a source 
S and a public destination D, S uses a single round of Sphinx 03], 
a provably secure mix protocol (an overview of Sphinx is given 
in Section l4.3.1b . This round consists of two Sphinx packets (one 
for the forward path and one for the backward path) each of which 
will anonymously establish shared symmetric keys between S and 
every node on that path. Eor HORNET, we extend the Sphinx pro¬ 
tocol to additionally anonymously collect the forwarding segments 
(ESes) for each node. Our modified Sphinx protocol protects the 
secrecy and integrity of these ESes, and does not reveal topology 
information to any node on the path. We note that using Sphinx 
also for data forwarding would result in low throughput due to pro¬ 
hibitively expensive per-hop asymmetric cryptographic operations. 
Therefore, we use Sphinx only for session setup packets, which 
are amortized over the subsequent data transmission packets. We 
explain the details of the setup phase in Section l43] 

Data transmission phase. Having collected the ESes, the source 
is now able to construct a forward AHDR and a backward AHDR 
for the forward and backward paths, respectively. AHDRs carry the 


ESes which contain all state necessary for nodes to process and 
forward packets to the next hop. When sending a data packet, the 
source onion-encrypts the data payload using the session’s shared 
symmetric keys, and prepends the AHDR. Each node then retrieves 
its ES from the AHDR, onion-decrypts the packet and forwards it to 
the next hop, until it reaches the destination. The destination uses 
the backward AHDR (received in the first data packeQ) to send data 
back to S, with the only difference being that the payload is en¬ 
crypted (rather than decrypted) at each hop. We present the details 
of the data transmission phase in Section I4A1 

3.2 Sender-Receiver Anonymity 

Sender-receiver anonymity, where neither S nor D knows the 
other’s location (e.g., a hidden service), presents a new challenge: 
since S does not know D’s location (and vice versa), S cannot 
retrieve a path to D, precluding the establishment of state between 
S and nodes on the path to D as described in Section[3T] 

A common approach to this problem (as adopted by Tofl LAP, 
and Dovetail) is to use a public rendezvous point (RP) to forward 
traffic between S and D without knowing either S oi D. This 
solution would also work for HORNET, but would require RPs to 
maintain per-session state between sources and destinations. Eor 
instance, when receiving a packet from S, an RP needs the state to 
determine how to send the packet to D. Maintaining per-session 
state on RPs increases complexity, bounds the number of receivers, 
and introduces a state exhaustion denial-of-service attack vector. 
Nested AHDRs. Our proposal for sender-receiver anonymity re¬ 
quires no state to be kept at the RP by nesting the necessary state 
for RPs to forward a packet within the packet’s header: a forward 
AHDR from S to a RP will include the AHDR from the RP to D; a 
backward AHDR from D to a RP will include the AHDR from the 
RP back to S. 

Briefly, to establish a HORNET session between S and D keep¬ 
ing both parties hidden from each other, D selects a public ren¬ 
dezvous point R and completes a HORNET session setup between 
D and R. D publishes AHDR/{_j,£) to a public directory. Note that 
this AHDR leaks no information about D’s location and can only be 
used to send data to D through R within a specific time window. 

When S wants to send traffic to D, S retrieves (from a public 
directory) AHDR/j^^;. S then establishes a HORNET session be¬ 
tween S and R and constructs a nested AHDR with AHDR/{_j,£) 
inside AHDR 5 ^/j. Thus, when R receives a packet from S, R can 
retrieve AHDR/{_^£) from AHDR 5 _^/{ and forward the packet to 
D. S also includes AHDR/j ^5 in the data payload of the first data 
packet to D, allowing D to create a return path to S. 

One of the advantages of our scheme is that any node on the net¬ 
work can serve as a rendezvous point. In fact, multiple points can 
be selected and advertised, allowing the source to pick the RP clos¬ 
est to it. Moreover, once a HORNET session has been established, 
S and D can negotiate a better (closer) RP (e.g., using private set 
intersection Oi)- A disadvantage of the nested AHDR technique is 
that it doubles the size of the header. 

3.3 Packet Structure 

HORNET uses two types of packets: setup packets and data 
packets (see EigurefT]. Both types of packets begin with a com- 

^If the first packet is lost the source can sim ply re send the backward 
AHDR using a new data packet (see Section l4!4l l. 

^Tor additionally uses an introduction point, which enables S to 
negotiate a rendezvous point with D. This design provides addi¬ 
tional scalability and attack resistance 1261 , but increases the delay 
of setting up a session. HORNET’S design favors simplicity and 
performance, but nothing fundamentally prevents HORNET from 
using Tor’s approach. 
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mon header (CHDR) which describes the packet type, the length of 
the longest path that the session supports, and a type-specific field. 
For session setup packets, the type-specific field contains a value 
EXP which indicates the intended expiration time of the session. 
For data packets, the specific value is a random nonce generated by 
the sender used by intermediate nodes to process the data packet. 

Session setup packets include a nested Sphinx packet and an FS 
payload. Data packets carry an AHDR and an onion-encrypted data 
payload. We explain each field in detail in Section|4l 


HORNET Setup Packet 


HORNET Data Packet 

type hops EXP 


type hops nonce 

Sphinx Header 

AHDR 

Sphinx Payload 

Data Payload 

FS Payload 


Figure 1: HORNET packet formats. For both setup packet and 
data packet, the shaded fields represent the common header 

(CHDR). 


4. FORMAL PROTOCOL DESCRIPTION 

We now describe the details of our protocol, focusing on sender 
anonymity. We begin with notation (Section r4.1l > and initialization 
requirements (Section|4j3- We then describe the establishment of 
anonymous communication sessions (Section |43J and data trans¬ 
mission (Section r4.4b . 

4.1 Notation 

Let k be the security parameter used in the protocol. For evalua¬ 
tion purposes we consider k = 128. is a prime order cyclic group 
of order g (g ~ 2^*), which satisfies the Decisional Diffie-Flellman 
Assumption. Q* is the set of non-identity elements in Q and (? is a 
generator of Q. Throughout this section we use the multiplicative 
notation for G. 

Let r be the maximum length of a path, i.e., the maximum num¬ 
ber of nodes on a path, including the destination. We denote the 
length of an FS as \FS\ and the size of an AHDR block, containing 
an FS and a MAC of size k, as c= IT’S! + k. 

HORNET uses the following cryptographic primitives: 

• MAC : {0,1}^ X {0,1}* —>■ {0,1}^: Message Authentication 
Code (MAC) function. 

• PRGO, PRGl, PRG2 : {0,1}^ {0,1}’’'^: Three cryptographic 

pseudo-random generators. 

• PRP : {0,1}^ X {0,1}“ —>■ {0,1}“: A pseudo-random permu¬ 
tation, implementable as a block cipher. The value of a will be 
clear from the context. 

• ENC : {0,1}'= X {0,1}'= X {0,1}™'= ^ {0,1}™'=: Encryption 
function, with the second parameter being the Initialization Vec¬ 
tor (IV) (e.g., stream cipher in CBC mode), m is a positive inte¬ 
ger denoting the number of encrypted blocks. 

• DEC : {0,1}'= X {0,1}'= X {0,1}™'= ^ {0,1}™'=: Decryption 
function, inverse of ENC. 

• hop : G* —^ {0,1}'=: a family of hash functions used to key op, 
with op G {MAC, PRGO, PRGl, PRP, ENC, DEC}. 


Term 

Definition 

k 

Security parameter (length of keys and MACs). k — 128 bits (16 
B). 

\FS\ 

Length of a forwarding segment (FS). — 256 bits (32 B). 

c 

Length of a typical block made of an FS and a MAC. c — + 

k ^ 384 bits (48 B). 

r 

Maximum path length, including the destination. From our evalu¬ 
ation, r — 7. 

S,D 

Source and destination. 


The forward path (from S to D) and the backward path (from D to 

S). 

iRi” 

Lengths of the forward and backward path {1, when it is clear from 
the context to which path it refers). From our evaluation, 1 < Z < 

7. 

f b 
ni,n. 

The 2 -th node on the forward path and the j-th node on the back¬ 
ward path, with 0 < i < and 0 < j 


Public/private key pair of node n. 

4 

Secret key established between S and node . 

R 

Routing information, which allows a node to forward a packet to 
the next hop. 

CHDR 

Common header. First three fields of both setup packets and data 
packets (see Figurefn. 

SHDR,SP 

Sphinx header and payload. 

P 

FS payload, used to collect the FSes during the setup phase. 

AHDR 

Anonymous header, used for every data packet. It allows each 
node on the path to retrieve its FS. 

o 

Onion payload, containing the data payload of data packets. 

EXP 

Expiration time, included in each FS. 


Table 1: Protocol notation and typical values (where applica¬ 
ble). 


We denote by RAND(a) a function that generates a new uniformly 
random string of length a. 

Furthermore, we define the notation for bit strings. 0“ stands for 
a string of zeros of length a. \a\ is the length of the bit string a. 
a[a {,] represents a substring of a from bit a to bit b, with sub¬ 
index a starting from 0; (y]^o...end] indicates the substring of a from 
bit a till the end. e is the empty string, a || a' is the concatenation of 
string (T and string a . We summarize protocol notation and typical 
values for specific parameters in Table[T] 

In the following protocol description, we consider a source S 
communicating with a destination D using forward path travers¬ 
ing nodes tIq , ,..., njf _ ^ and backward path traversing nodes 

nQ,n\,... with 1^,1^ < r, where and n^b_i are the 

nodes closest to the source. Without loss of generality, we let the 

f 

last node on the forward path = D and refer to the desti¬ 

nation by these two notations interchangeably. In general we use 
dir G {f,b} as superscripts to distinguish between notation refer¬ 
ring to the forward and backward path, respectively. Finally, to 
avoid redundancy, we use {symf^''} to denote {symf^^\0 < i < 
\vjiere sym can be any symbol. 

4.2 Initialization 

Suppose that a source S wishes to establish an anonymous ses¬ 
sion with a public destination D. First, S anonymously obtains 
(from the underlying network) paths in both directions: a forward 
path p^ = { Rq , , • • • , R^f _ } from S' to D and a backward path 

p^ — {Rq,R\,--- ,Rji,_i} front D to S. i?*’’ denotes the rout¬ 
ing information needed by the node to forward a packet. S 
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also anonymously retrieves and verifies a set of public keys g "‘i" 
for the node on path (see Section IzTl l. Note that 
is also included in the above set (as = D). Finally, S gen¬ 

erates a random DFl public/private key pair for the session: xg 
and . The per-session public key is used by the source to 
create shared symmetric keys with nodes on the paths later in the 
setup phase. S locally stores |( 2 : 5 ,and 
uses these values for the setup phase. 

4.3 Setup Phase 

As discussed in Section [3] in the setup phase, HORNET uses 
two Sphinx packets, which we denote by PO and P©, to traverse 
all nodes on both forward and backward paths and establish per- 
session state with every intermediate node, without revealing S’^ 
network location. For S to collect the generated per-session state 
from each node, both Sphinx packets contain an empty FS payload 
into which each intermediate node can insert its FS, but is not able 
to learn anything about, or modify, previously inserted FSes. 

4.3.1 Sphinx Overview 

Sphinx (23] is a provably-secure mix protocol. Each Sphinx 
packet allows a source node to establish a set of symmetric keys, 
one for each node on the path through which packets are routed. 
These keys enable each node to check the header’s integrity, onion- 
decrypt the data payload, and retrieve the information to route the 
packet. Processing Sphinx packets involves expensive asymmet¬ 
ric cryptographic operations, thus Sphinx alone is not suitable to 
support high-speed anonymous communication. 

Sphinx packets. A Sphinx packet is composed of a Sphinx header 
SHDR and a Sphinx payload SP. The SHDR contains a group ele¬ 
ment that is re-randomized at each hop. Each is used 
as ephemeral public key in a DH key exchange with node 
Erom this DH exchange, node derives a shared symmetric 
key sf", which it uses to process the rest of the SHDR and mutate 
y^dir jjjg jjjg SHDR is an onion-encrypted data structure, 

with each layer containing routing information and a MAC. The 
routing information indicates to which node the packet should be 
forwarded to next, and the MAC allows to check the header’s in¬ 
tegrity at the current node. The Sphinx payload SP allows end hosts 
to send confidential content to each other. Each intermediate node 
processes SP by using a pseudo-random permutation. 

Sphinx core functions. We abstract the Sphinx protocol into the 
following six functions: 

• GEN_SPHX_HDR. The source uses this function to generate two 
Sphinx headers, SHDR-^ and SHDR^, for the forward and back¬ 
ward path, respectively. It also outputs the symmetric keys {sf^''}, 
each established with the corresponding node’s public key g . 

• GEN_SPHX_PL_SEND. The function allows the source to gener¬ 
ate an onion-encrypted payload SP-^ encapsulating confidential 
data to send to the destination. 

• UNWRAP_SPHX_PL_SEND. The function removes the last en¬ 
cryption layer added by GEN_SPHX_PL_SEND, and allows the 
destination to decrypt the SP-^. 

• GEN_SPHX_PL_RECV. The function enables the destination to 
cryptographically wrap a data payload into SP^ before sending it 
to the source. 

• UNWRAP_SPHX_PL_RECV. The function allows the source to 
recover the plaintext of the payload that the destination sent. 

• PROC_SPHX_PKT. Intermediate nodes use this function to pro¬ 
cess a Sphinx packet, and establish symmetric keys shared with 


the source. The function takes as inputs the packet (SHDR,SP), 

X dir 

and the node’s DH public key g . The function outputs the 

processed Sphinx packet (SHDR^,SP^) and the established sym¬ 
metric key sf". 

4.3.2 Forwarding Segment 

We extend Sphinx to allow each node to create a Eorwarding 
Segment (ES) and add it to a data structure we name ES payload 
(see below). An ES contains a node’s per-session state, which con¬ 
sists of a secret key s shared with the source, a routing segment R, 
and the session’s expiration time EXP. To protect these contents, the 
ES is encrypted with a PRP keyed by a secret value SV known only 
by the node that creates the FS. A node seals and unseals its state 
using two opposite functions: FS_CREATE and PS_OPEN. They are 
defined as follows: 

FS = ps_create(5H, s, R, exp) = 

= PRP(/iPRp(SH);{s||i?||EXP}) 

{s II II exp} = fs_open(5'1/', FS) 

= PRP~\hpRp{SV)-,FS) 

4.3.3 FS Payload 

At the end of each HORNET setup packet is a data structure 
we call FS payload (see Figure [T). The FS payload is an onion- 
encrypted construction that allows intermediate nodes to add their 
FSes as onion-layers. 

Processing the FS payload leaks no information about the path’s 
length or about an intermediate node’s position on the path. All 
FS payloads are padded to a fixed length, which is kept constant 
by dropping the right number of trailing bits of the FS payload 
before an FS is added to the front. Moreover, new FSes are always 
added to the beginning of the FS payload, eliminating the need for 
intermediate nodes to know their positions in order to process FS 
payloads. 

An FS payload also provides both secrecy and integrity for the 
FSes it contains. Each node re-encrypts the ES payload after in¬ 
serting a new ES and computes a MAC over the resulting structure. 
Only the source, with symmetric keys shared with each node on a 
path, can retrieve all the FSes from the FS payload and verify their 
integrity. 

Functions. There are three core functions for the FS payload: 
INIT_FS_PAYLOAD, ADD_FS, and RETRIEVE_FSES. 

INIT_FS_PAYLOAD. A node initializes an FS payload by using a 
pseudo-random generator keyed with a symmetric key s to generate 
rc random bits: 

P=PRGl(/ipRGi(s)) (3) 

where c = |f’S'| -F A: is the size of a basic block of the FS payload 
(consisting of an FS and a MAC). 

ADD_FS. Each intermediate node uses ADD_FS to insert its ES 
into the payload, as shown in Algorithm [T] First, the trailing c bits 
of the current FS payload, which are padding bits containing no 
information about previously added FSes, are dropped, and then 
the FS is prepended to the shortened FS payload. The result is 
encrypted using a stream cipher (Line O and MACed (Line |4). 
Note that no node-position information is required in ADD_PS, and 
verifying that the length of the FS payload remains unchanged is 
straightforward. 

RETRIEVE_PSES. The source uses this function to recover all 
FSes {FSi} inserted into an FS payload P. RETRIEVE_PSES starts 
by recomputing the discarded trailing bits (Line |3 and obtaining a 
complete payload PfuU- Thus, intuitively, this full payload is what 
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Algorithm 1 Add FS into FS payload. 

1 : procedure add_fs 
Input: s, FS, Pin 
Output: Pout 

2: II ^ira[0..(r-l)c-l] I 

© PRGO(/lpRGo(s))[fc end] 
3: ot i MAC(/t[\/|/\G(^)i 

4: Pout Q: II Pimp 

5: end procedure 


Algorithm 2 Retrieve FSes from FS payload. 

1: procedure RETRIEVE_FSES 
Input: P, s, {si} 

Output: {FSi} 

2: Pinit ^ INIT_FS_PAYLOAD(s) 

3- t/j Pinit [(^r—l)c. .rc—l] 

© PRGO(/lpRGo(so))[(r-Z+l) c..end] II ^ 

© PRGO(/lpRGo(si))[(r_i+2) c..end] II ^ 

© PRGO(/lpRGo(st- 2 ))[(r-l)c..end] II 

4: Pfull = -P II t/> 

5: for i •(—(I — 1),... ,0 do 

6: checkPy„i,jQ = 

MAG(/l|v|Ac(Si);P’/nii[j, ^e-lj) 

7: Pjnii ^ Pfull © (PRGO(ItpRGo(s.)) II 

8 : ^full[k..c-l] 

9 : ^-^/““[c..end] 

10: end for 

11: end procedure 


would remain if no nodes dropped any bits before inserting a new 
FS. Afterwards, the source retrieves the FSes from Pfull in the 
reverse order in which they were added by ADD_FS (see lines 
and[^. 

4.3.4 Setup Phase Protocol Description 
Source processing. With the input 

the source node S bootstraps a session setup in 5 steps: 

1. S selects the intended expiration time EXP for the session and 
specifies it in the common header CHDR (see Section[33}0 

2. S generates the send and the reply Sphinx headers by: 

{SHDR^,SHDR*'} = GEN_SPHX_HDR(/, CHDR) (4) 

The common header CHDR (see Figure[TJ is passed to the func¬ 
tion to extend the per-hop integrity protection of Sphinx over it. 
GEN_SPHX_HDR also produces the symmetric keys shared with 
each node on both paths 

^EXP must not become an identifier that allows matching packets 
of the same flow across multiple links. Since EXP does not change 
during setup packet forwarding, a coarser granularity (e.g., 10s) is 
desirable. In addition, the duration of the session should also have 
only a restricted set of possible values (e.g., 10s, 30s, Imin, lOmin) 
to avoid matching packets within long sessions. For long-lived con¬ 
nections, the source can create a new session in the background 
before expiration of the previous one to avoid additional latency. 


3 . In order to enable the destination D to reply, S places the reply 
Sphinx header SHDR^ into the Sphinx payload: 

SP-^ = GEN_SPHX_PL_SEND({s/}, SHDR^) (5) 

4. S creates an initial FS payload P^ = INIT_FS_PAYL0AD(a;5). 

5. S composes PO = {CHDR || SHDR-^ || SP-^ || and sends it to 

f 

the first node on the forward path Uq . 

Intermediate node processing. An intermediate node nf receiv¬ 
ing a packet PO = {CHDR || SHDR-^ || SP-^ || P^} processes it as 
follows: 

1. nj first processes SHDR-^ and SP-^ in PO according to the 
Sphinx protocol (using PROC_SPHX_PKT). As a result n{ ob¬ 
tains the established symmetric key sj shared with S, the pro- 

rf rf 

cessed header and payload (SHDR-' ,SP'' ) as well as the rout¬ 
ing information During this processing the integrity of the 
CHDR is verified. 

f 

2. nt obtains EXP from CHDR and checks that EXP is not expired. 

f f 

nt also verifies that Rt is valid. 

3 . generates its forwarding segment by using its local sym¬ 
metric key SV/ to encrypt sf , pf, and EXP (see Equation[T): 

FS{ = fs_create{SV/,s{,r{,exp) (6) 

4. nf adds its FS( into the FS payload PP 

P^'= ADD_ES{s{ ,FS{ ,P^) ( 7 ) 

£ 

5. Finally node assembles the processed packet PO = {CHDR || 
SHDR-^ II SP-^ II P^ } and routes it to the next node according 

f 

to the routing information Rt. 

Destination processing. As the last node on the forward path, D 
processes PO in the same way as the previous nodes. It first pro¬ 
cesses the Sphinx packet in PO and derives a symmetric key sjj 
shared with S, and then it encrypts per-session state, including so, 
into FSo, and inserts FSjj into the FS payload. 

After these operations, however, D moves on to create the sec¬ 
ond setup packet P@ as follows: 

1. D retrieves the Sphinx reply header using the symmetric key 
sd- 

SHDR^ = UNWRAP_SPHX_PL_SEND(s£),SP'^) (8) 

2. D places the FS payload P-^ of PO into the Sphinx payload SP^ 
of P@ (this will allow S to get the FSes {Fsf }): 

sp^ = gen_sphx_pl_recv(s£),P'^) (9) 

Note that since D has no knowledge about the keys } except 
for So, D learns nothing about the other FSes in the FS payload. 

3 . D creates a new FS payload P^ = INIT_FS_PAYLOAD(s£)) to 
collect the FSes along the backward path. 

4. D composes P@ = {CHDR || SHDR^ || SP^ || P^} and sends it to 
the first node on the backward path, tiq. 

The nodes on the backward path process P@ in the exact same 
way nodes on the forward path processed PO. Finally P© reaches 
the source S with FSes {FSi} added to the FS payload. 

Post-setup processing. Once S receives P@ it extracts all FSes, 
i.e., {Fs{ } and }, as follows: 
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1. S recovers the FS payload for the forward path from SP^: 

= UNWRAP_SPHX_PL_RECV({Si }, SP^) (10) 

2. S retrieves the FSes for the nodes on the forward path {FSj }: 

{FS{ } = RETRIEVE_FSES({s{ },P^) (11) 

3. S directly extracts from P^the FSes for the nodes on the back¬ 
ward path {FS^}'. 

{P5j} = retrieve_eses({4},-P^) (12) 

With the FSes for all nodes on both paths, {Fs{ } and {PS^}, S 
is ready to start the data transmission phase. 

4.4 Data Transmission Phase 

Each FIORNET data packet contains an anonymous header AHDR 
and an onion-encrypted payload O as shown in Figure[T] Figure[2 
illustrates the details of an AHDR. The AHDR allows each inter¬ 
mediate node along the path to retrieve its per-session state in the 
form of an FS and process the onion-encrypted data payload. All 
processing of data packets in FIORNET only involves symmetric- 
key cryptography, therefore supporting fast packet processing. 

Anonymous Header Forwarding Segment (FS) 

" 0 _ _8 _ 1^6 

(• ^ . Sha/ed Key • • (- ( 

■/ '-R' ' . -EXP-'' . ■ 

... Encrypted 

Onion Encrypted 


FS 


MAC 


Blinded FSes 


Figure 2: Format of a HORNET anonymous header with de¬ 
tails of a forwarding segment (FS). 

At the beginning of the data transmission phase, S creates two 
AHDRs, one for the forward path (AHDR^) and one for the back¬ 
ward path (AHDR^), by using FSes collected during the setup phase. 
AHDR-^ enables S to send data payloads to D. To enable D to trans¬ 
mit data payloads back, S sends AHDR^ as payload in the first data 
packet. If this packet is lost, the source would notice from the fact 
that no reply is seen from the destination. If this happens the source 
simply resends the backward AHDR using a new data packet. 

4.4.1 Anonymous Header 

Like an FS payload, an AHDR is an onion-encrypted data struc¬ 
ture that contains FSes. It also offers the same guarantees, i.e., 
secrecy and integrity, for the individual FSes it contains, for their 
number and for their order. Its functionalities, on the other hand, 
are the inverse: while the FS payload allows the source to collect 
the FSes added by intermediate nodes, the AHDR enables the source 
to re-distribute the FSes back to the nodes for each transmitted data 
packet. 


Algorithm 3 Process an AHDR. 

1: procedure proc_ahdr 
Input: SV, AHDR 
Output: s, R, AHDr' 

2: {F5II 7 11^}^ AHDR 

3: {s II R II exp} t- fs_open(S'V",F5') 

4: check 7 = MAC(fiMAc(s);FS II/3) 

5: check tcurr EXP 

6: ahdr'^ {/3||0^}©PRG2(fipRG2(s)) 

7: end procedure 


Algorithm 4 Anonymous header construction. 

1 : procedure create_ahdr 
Input: {si}, {FSi} 

Output: (F5o,7o,/3o) 

2: 00 ^ e 

3: for f •(—0,...— 2 do 

4: 0,+i^(0,||O“) 

© |pRG 2 (/ipRG 2 (si))[( 

r—l—i)c..end] ^ 

5: end for 

6: ;3;_1 •(-RAND ((r-l)c) II 0;_1 

2: 7;-i MAG(/imac(s;-i);7^5;_i || 

8: for i (1 — 2),.. .,0 do 

9: Pi •<— II 7i+i II /3i+ng —2)c—i]} 

© PRG2(fipRG2(Si))[0..(r-l)c-l] 

10: 7, ^MAG(fiMAc(s*);FS,||/3,) 

11: end for 

12: end procedure 


the key s shared with the source, as well as the routing informa¬ 
tion R, from the FS of the node invoking the function. Finally, 
PROC_AHDR also returns the processed header AHDR^ which will 
be used by the next hop. The details of this function can be seen in 
Algorithm]^ 

Our AHDR construction resembles the Sphinx packet header 
construction (23). For each path (forward and backward), 
CREATE_AHDR enables S to create an AHDR given the keys {s^} 
shared with each node on that path, and given the forwarding seg¬ 
ments {FSi} of those nodes. All these keys and FSes are obtained 
during the setup phase (see Section 143) . The details are shown 
in Algorithm O In essence, CREATE_AHDR is equivalent to a se¬ 
ries of PROC_AHDR iterations performed in reverse. Initially, the 
paddings 0 are computed, each of which is the leftmost part of 
an AHDR that results from the successive encryptions of the zero- 
paddings added in PROC_AHDR (0o is the empty string since no 
padding has been added yet). Once the last padding is computed 
(the one for the AHDR received by the last hop, 0;_i), the op¬ 
erations in PROC_AHDR are reversed, obtaining at each step the 
AHDRs as will be received by the nodes, from the last to the first. 
This also allows the computation of the per-hop MACs. 


Functions. The life cycle of AHDRs consists of two functions: 
the header construction (CREATE_AHDR) and the header process¬ 
ing (PROC_AHDR). We begin with the description of PROC_AHDR 
since it is simpler, and its helps understand the construction of 
CREATE_AHDR.PROC_AHDR allows each intermediate node to ver¬ 
ify the integrity of an incoming AHDR, and to check that the cor¬ 
responding session has not expired. PROC_AHDR also retrieves 


4.4.2 Onion Payload 

HORNET data payloads are protected by onion encryption. To 
send a data payload to the destination, the source adds a sequence 
of encryption layers on top of the data payload, one for each node 
on the forward path (including the destination). As the packet is 
forwarded, each node removes one layer of encryption, until the 
destination removes the last layer and obtains the original plaintext. 
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To send a data payload back to the source, the destination adds 
only one layer of encryption with its symmetric key shared with 
the source. As the packet is forwarded, each node on the backward 
path re-encrypts the payload until it reaches the source. With all 
the symmetric keys shared with nodes on the backward path, the 
source is capable of removing all encryption layers, thus obtaining 
the original data payload sent by the destination. 

Functions. Processing onion payloads requires the following two 
functions: ADD_LAYER and REMOVE_LAYER. 

ADD_LAYER. The function’s full form is: 

{O',/!/'} = add_layer(s,71/,0) (13) 

Given a symmetric key s, an initial vector IV, and an input onion 
payload O, ADD_LAYER performs two tasks. First, ADD_LAYER 
encrypts O with s and IV: 

O'= ENC{hENc{sy,IV-,0) (14) 

Then, to avoid making the IV an identifier across different links, 
ADD_LAYER mutates the IV for the next node: 

71/' = PRP(/ipRp(s);/y) (15) 

REMOVE_LAYER. The function is the inverse of ADD_LAYER, 
decrypting the onion payload at each step, and mutating the IV 
using the inverse permutation PRP^^ keyed with /ipRp(s). Its full 
form is the following: 

{o' ,IV'} = remove_layer(s,7I/,0) (16) 

4.4.3 Initializing Data Transmission 

To start the data transmission session, S generates AHDR-^ and 
AHDR^ as follows: 

AHDR-^ = CREATE_AHDR({s{},{F’5f}) (17) 

AHDR^ = CREATE_AHDR({Si},{7’5'i}) (18) 

S then sends AHDR^ to D as payload of the first data packet (which 
uses AHDR-^), as specified in the following section. 

4.4.4 Data Transmission Protocol Description 

Source processing. With ahdr-^, S can send a data payload M 
with the following steps: 

1. S ensures that the session is not expired by checking that the 
current time tcurr < EXP. 

£ 

2. S creates an initial IV. With the shared keys {st }, S onion 

encrypts the data payload M by setting O;/ = M and 7V;/ = 
IV and computing the following for i •<— — 1)..0: 

{Oi,IVi} = add_layer(s, , 7^;+!, Oj+i) (19) 

3. S places 7Vb in the common header CHDR. 

4. S sends out the resulting data packet {CHDRjAHDR-^, Oq}- 

Processing by intermediate nodes. Each intermediate node 
on the forward path processes a received data packet of the form 
{CHDR, AHDR-^jO} with its local secret key SV/ as follows: 
f f 

1. nt retrieves the key st shared with S and the routing informa¬ 
tion from AHDR-^: 

{s{,77{,ahdr'^^} = proc_ahdr(S'17/,ahdr'^) (20) 

PROC_AHDR also verifies the integrity of AHDR, and checks that 
the session has not expired. 


f 

2. nt obtains IV from CHDR and removes one layer of encryption 
from the data payload: 

{o', 71/'} = REMOVE_LAYER(sf , IV, O) (21) 

3. nf updates the IV field in CHDR with IV'. 

4. nf sends the resulting packet {chdr'jAHDR-^^, O'} to the next 

f 

node according to Rt. 

The above procedures show that the intermediate node process¬ 
ing requires only symmetric-cryptography operations. 

Destination processing. D processes incoming data packets as 
the intermediate nodes. Removing the last encryption layer from 
the onion payload D obtains the original data payload M sent by 

5. Additionally, for the first data packet D retrieves AHDR^ from 
the payload, and stores the {s/5 ,77 q,AHDR^} locally so that D can 
retrieve AHDR^ when it wishes to send packets back to S. 

Processing for the backward path. Sending and processing a 
HORNET packet along the backward path is the same as that for the 
forward path, with the exception of processing involving the data 
payload. Because D does not possess the symmetric keys that each 
node on the backward path shares with S, D cannot onion-encrypt 
its payload. Therefore, instead of REMOVE_LAYER, D and the in¬ 
termediate nodes use ADD_LAYER to process the data payload, and 
the source node recovers the data with REMOVE_LAYER. 

4.5 Nested Anonymous Header Construction 

As discussed in Section[T2] the main difference of the protocols 
between sender anonymity and sender-receiver anonymity is that 
the latter requires nested AHDRs. We present in detail the process 
of composing an AHDR with a nested AHDR in Algorithm|5] 
Constructing a new AHDR based on a nested AHDR A has es¬ 
sentially the same procedures as constructing a normal AHDR from 
ASes, except for the initialization process and the size of the re¬ 
sulted AHDR. For the AHDR initialization in Line [TO] in Algo- 
rithm[5l the nested AHDR A is perpended to the random bits gen¬ 
erated. Thus, when the last node n*’' (RP) decrypts the AHDR, A 
is revealed to the node. For the size of the resulting AHDR, instead 
of r for a normal AHDR, the length of the generated AHDR with a 
nested AHDR is 2r, doubling the bandwidth cost incurred by the 
protocol headers. 

5. SECURITY ANALYSIS 

In this section, we first present formal proofs showing that HOR¬ 
NET satisfies the correctness, security, and integrity properties de¬ 
fined by Camenisch and Lysyanskaya (H. Then, we describe how 
HORNET defends against well-known de-anonymization attacks 
and meets the design goals of Section l23] We also present defenses 
against denial of service attacks. 

5.1 Formal Proof of Security for HORNET Data 
Transmission Phase 

We prove HORNET’S data transmission phase realizes ideal onion 
routing functionalities in the Universal Composability (UC) frame¬ 
work HU. Conceptually, with an ideal onion routing protocol, ad¬ 
versaries have no access to the routing information or the message 
within packets except for opaque identifiers that vary across links. 

As demonstrated by Camenisch and Lysyanskaya CD, to prove 
that a protocol conforms to an ideal onion routing model, it is suf¬ 
ficient to show that the protocol provides four properties: correct¬ 
ness, integrity, wrap-resistance, and security. 


8 


Algorithm 5 Creating an AHDR with a nested AHDR. 

1: procedure create_padding_string_nested 
Input: {si}, r 
Output: 

2: 00 ^ e 

3: for 0 < i < Z do 

4: (f>i <— {4>i-i II 0°)© 

5: {PRGO(ZlpRGo(Si-l))[(2r-j)c..2rc]} 

6: end for 

7: end procedure 

8: procedure create_anonymous_header_nested 
Input: {sj, {FS^}, A 
Output: (rao,7o,/3o) 

9: 0/_i •<— CREATE_PADDING_STRING_NESTED({Si}) 

10: /3i_i ^ {{A||RAND(c(r-Z))} 

© PRGO(ZlpRGo(s/-l))[o..c( 2 r-/)-l]} II 0/-1 

II: 7/_i MAC(/imac(s/-i);Z^‘S;_i \\Pi-i) 

12: fori^ (Z-2),...,0do 

13: Pi II 7i+l II Pi+l [0..c(2r—1) —1] ]■ 

© PRGO(ZlpRGo(Si))[o,,c( 2 r-i)-l] 

14: 7,^MAG(ZiMAc(sO;^’*S,||0,) 

15: end for 

16: end procedure 


5.1.1 Correctness 

Proving the correctness property requires that HORNET proto¬ 
col functions correctly in the absence of adversaries. A scrutiny of 
protocol description in Section|4] should suffice. 

5.1.2 Integrity 

To prove the integrity property, we need to prove that an adver¬ 
sary cannot forge a message that can traverse more than N uncom¬ 
promised nodes, where Q is a fixed upper bound for HORNET. 
Equivalently, we demonstrate that an adversary, with significantly 
less than 2 ^ computation, can only produce a requisite message 
with a negligible probability. In our proof, we choose Q = r + 1. 

Suppose that an adversary can construct a HORNET AHDR {FSq, 
70 , Po) that can succeed in traversing r + 1 honest nodes ng, n 2 , 

..., Ur, without knowing secrets 5Vb, ..., SVr- According to Al¬ 
gorithm!?] FSr, Pr, and 7r satisfy: 

7 . = MAC{hMAc{PRP~\hpRp(SVry,FSr)[o..c]y,Pr) ( 22 ) 

Eor convenience, for i < y < r — 1, we introduce the following 
notation: 


4>{SV,FS) 

= PRp-\hpRp{SV)-,FS) 

(23) 

p{SV,FS) 

= PRC{hpRG{P{SV,FS))) 

(24) 

Pi 

= p{SV„FS*) 

(25) 

Pi^ 

{Pi^[c{r — l — i)..c(r—l—i)-\-lps — l] 

(26) 

p1 

]-P^}[c(r —1 — 7 +^r’ 5 ..c(r—i) —1] 

(27) 

p^ 

= {Pi}[0..c(i-|-1)-1] ^ 

(28) 

c 

Pi,j 

“ {p*}[yc..(y-i-i)c-i] 

(29) 


where FS* are defined recursively as follows: 

FS^ = FSo (30) 

i-l 

FS* = (31) 

7=0 


We observe that FS* is a function of {FSj | VO < y < i} and 
{SVj I VO < y < i — 1}. Accordingly, pi, and pf are all 
functions of {FSj | VO < y < i} and VO < y < i — 1}. 

With a detailed inspection of Algorithm]?] we can express FSr, 
Pr, and 7r-: 


r—1 

0pf" 

(32) 



r—1 


0p7 

(33) 

2^0 


r—1 


©rf 

(34) 

2^0 

(35) 


With Equation HUH] l3?l and HU we can prove the following 
lemma: 

Lemma 1. With less than 2^ work, an adversary can only dis¬ 
tinguish M AC {h mac {PiRCr, FSr) \y)p^)\Pr) from a random or¬ 
acle with negligible probability. 

Proof. (Sketch) We will show that an adversary cannot find two 
sets of 

[SVo,. ..,SVr,FSo..., FSr-i) y (svy ..., SI/;, ..., FSp_i) 

that lead to the same value of M AC {Km AC {PiRCr, FSr) [q (.])\Pr) 
with significant less than 2* work. Assume that the adversary, with 
much less than 2 ^ work, finds two sets, 

{SVo,..., SVr, FSo . • •, FSr) 7^ {SVi, ...,SV;,FS'q..., FS'r) 
that results in the same value of 

MAC{hMAc{<l>{SVr,FSr)[o..c]yPr) 

We will show the assumption leads to a contradiction. 

Because MAC is a random oracle, the only way for an attacker 
to distinguish the target function from a random oracle with much 
less than 2 ^ work is to ensure 

P(SVr,FSr)[ 0 ..c]=f{SV;,FS'r)[ 0 ..c\ 

and Pr = Pr- Because PRP is a pseudo-random permutation and 
hpRp is collision resistant, we have SVr = SVr- 

Note that the last cbits of Pr and Pr are pr-i r-i Pr_i , i 

respectively. Therefore, we have Pr_i , _ i = Pr—i r-l ■ 

cording to Equation HU because PRC is a pseudo-random gen¬ 
erator, we have 5V;_i = SVr-i and FS*_i = FS*_i . Hence, 

Pr-l j = Pr-l /’ VO < y < r — 1. 

A careful calculation shows that the c bits before the last c bits in 

Pr and^; are p;_2^r-2® Pr-l,r-2 and Pr-2,r-2 ® Pr-l,r-2 ■ 
Similarly, we have SVr -2 = SVr-f and FS *_2 = FS;_ 2 . 

Continuing the logic as above, we finally have SVi = SVi and 
FS* = FS*', VO < i < r — 1. However, given EquationHU SVi = 
51//, and FS^ = FS^', we have FSi = FS'„ VO < i < r -1. This 
results in 

{SVo,. ..,SVr,FSo..., FSr-i) = {SVi, ■■■,SV;,FSi..., FSp-i) 

Therefore, we obtain a contradiction. □ 

We can substitute Equation HU HU andHUinto EquationHU and 
rewrite the equation into: 

r —1 

p-^^ = MAC{hMAc{f{SVr,FSr)lo..c]yPr)®^p] (36) 
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Because MAC is not used in pj, the right side of Equation[^is a 
random oracle with respect to SVi and FSi, VO < i < r — 1. 

We can further simplify the notation by denoting pg as fo{SVo,FSo) 
and the right side of EQuationl36las 

h{FSo,...,FSr-l,SVo,...,SVr-l) 

Both /o and fi are random oracles with range {0,1}^. As a result, 
by creating a AHDR traversing r + 1 honest nodes, the adversary 
equivalently finds a solution to 

fQ{SVQ,FSo) = h{FSo,...,FSr-i,SVo,...,SVr-i) 

which can only be solved with negligible probability with signifi¬ 
cantly less than 2^ work. Hence, with much less than 2^ work, the 
adversary can only generate a packet that traverse r + 1 hops with 
negligible probability. 

5.1.3 Wrap-resistance 

To prove the wrap-resistance property, we show that given a data 
packet {FS,^,I3,P), an adversary, with significant less than 2^ 
work, cannot generate a message {FS' ,'y' ,/3' ,P) so that process¬ 
ing {Fs' ,'y', P', P) on an uncompromised node yields data packet 
{FS,j,p,P). 

To succeed, it is necessary that: 

P(B{P'c..cr-i\\0''} = p{SV',FS') (37) 

Consider the last c bits of the left side of Equation[37] we have: 

/^[c(r—l)..cr—1] ^FS )[c(r —l)..cr —1] (38) 

Because PRG, PRP, hpnQ, and hppp are all random oracles, 
an adversary could generate FS' and SV' that satisfy Eauationl38l 
only with negligible probability if the adversary performs much 
less than 2^ work. 

5.1.4 Security 

To demonstrate the security property, we need to prove that an 
adversary with control over all nodes on a path except one node N, 
cannot distinguish among data packets entering N. The adversary 
is able to select paths for the packets traversing N and payloads 
of the packets. The adversary can also observe packets entering 
and leaving node N except for packets whose headers match the 
challenge packets. 

We construct the following game G. The adversary picks two 
paths (no,ni,.. 0 < a <r and (ng,n^,.. 0 < 

v' < r, where VO < z < j and nj = n'j = N. Note that 

the nodes after N in both paths are not necessarily the same set 
of nodes, and the lengths of the paths can also be different. The 
adversary chooses the public/private key pairs and SVASVl) for 
all nodes except N and can arbitrarily select payload M. 

The challenger picks randomly a bit b and proceeds in one of the 
following two ways: 

6 = 0: The challenger creates an AHDR (T’5'o,7o,/?o) through 
the HORNET setup phase using the path (no,ni,... ,ny_i) and 
uses it to construct a data packet with onion encrypted payload 
from M. The challenger outputs (T’5'o,7o,/3o,M®), which could 
be sent to ng. 

6=1: The challenger creates an AHDR (T’5'o,7o,/9o) using the 
alternative path (ng,n^,... instead and outputs 

(7^50,70,/3o,M®), which could be sent to ng. 

Given the output {FSo,'yojPo)y the adversary’s goal is to deter¬ 
mine 6. The adversary can also input any messages {FS' ,'y',P' 


to the honest node N and observes the output messages as long as 
{FS','y',p')^{FSj,'yj,Pj)E 

We define the adversary’s advantage as the difference between ^ 
and the probability that the adversary succeeds. We will show that 
the adversary’s advantage is negligible. Therefore, the adversary 
has no better chance to determine 6 than random guessing. 

Proof. (Sketch) We adopt the hybrid-game method. First, we con¬ 
struct a modified game Gi with exactly the same definition, except 
that we require j = 0. An adversary who can win G can thus imme¬ 
diately win Gi. On the other hand, because the adversary controls 
nodes {uq, ... ,nj_i) ({n'Q, ... ,n'j_i)) and can thus emulate their 
processing, the adversary can also win game G if he/she can win 
game Gi. Therefore, the adversary can win game G if and only if 
the adversary can win game Gi . 

We create a second game G 2 , which is the same as Gi except 
that FSq, Po, and 70 are all randomly generated from their corre¬ 
sponding domains. If the adversary can distinguish G 2 from Gi, 
we have: 

1. The adversary can distinguish 

FSo = PRP{hpRp(SVoy,Ro\\so) 

from randomness. Then it must be that the adversary is able 
to tell the output of a pseudo-random permutation with a ran¬ 
dom key (hppp{SVo)) from random bits. The probability 
of success for the adversary is negligible. 

2. The adversary can distinguish 

Po = PRG{hpRGiSVo)) © {FSi 11711 l/3i} 

from randomness. Then it must be the adversary is able to 
distinguish the output of a secure pseudo-random number 
generator with a random key (hpRQ{SVo)) from random¬ 
ness. The probability that the adversary succeeds is negligi¬ 
ble. 

3. The adversary can distinguish 

^o = MAC{hMAc{SVoy,Po) 

from randomness. Then it must be the adversary is able to 
distinguish the output of MAG with a random key hMAc{SVo) 
from randomness. Under our random oracle assumption for 
MAC, the probability of success is negligible. 

Therefore, the adversary cannot distinguish G 2 from Gi . 

Lastly, because in G 2 , {FSo,'yo,PQ) are all random, the adver¬ 
sary’s advantage is 0. Moreover, in our chain of game G —^ Gi —>■ 
G 2 , the adversary can only distinguish a game from its previous 
game with negligible probability. As a result, the adversary’s ad¬ 
vantage in game G is negligible. □ 

5.2 Passive De-anonymization 

Session linkage. Each session is established independently from 
every other session, based on fresh, randomly generated keys. Ses¬ 
sions are in particular not related to any long term secret or identi¬ 
fier of the host that creates them. Thus, two sessions from the same 
host are unlinkable, i.e., they are cryptographically indistinguish¬ 
able from sessions of two different hosts. 

Forward/backward flow correlation. The forward and backward 
headers are derived from distinct cryptographic keys and therefore 
cannot be linked. Only the destination is able to correlate forward 
and backward traffic, and could exploit this to discover the round- 
trip time (RTT) between the source and itself, which is common to 

^We follow the definition of security property m and only care 
about header uniqueness. 
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all low-latency anonymity systems. Sources willing to thwart such 
RTT-based attacks from malicious destinations could introduce a 
response delay for additional protection. 

Packet correlation. HORNET obfuscates packets at each hop. 
This prevents an adversary who observes packet bit patterns at two 
points on a path from linking packets between those two points. 
In addition to onion encryption, we also enforce this obfuscation 
by padding the header and the payload to a fixed length, thwart¬ 
ing packet-size-based correlation^ While this does not prevent 
the adversary from discovering that the same flow is passing his 
observation points using traffic analysis, it makes this process non¬ 
trivial, and allows upper-layer protocols to take additional measures 
to hide traffic patterns. The hop-by-hop encryption of the payload 
also hides the contents of the communication in transit, protect¬ 
ing against information leaked by upper layer protocols that can be 
used to correlate packets. 

Path length and node position leakage. HORNET protects against 
the leakage of a path’s length and of the nodes’ positions on the 
path (i.e., the relative distance, in hops, to the source and the desti¬ 
nation). In the setup phase, this protection is guaranteed by Sphinx, 
so only the common header and ES Payload are subject to leakage 
(see Section lT3] for the exact structure of the packets). It is straight¬ 
forward to see that the common header does not contain path or 
position information. The FS Payload length is padded to the max¬ 
imum size, and remains constant at each hop (see Algorithm [!}. 
After adding its FS to the front of the FS Payload, each node re¬ 
encrypts the FS payload, making it infeasible for the next nodes to 
see how many FSes have previously been inserted. 

During data transmission, neither the common header nor the 
data payload contain information about path length or node posi¬ 
tion, so only the AHDR (anonymous header) needs to be analyzed. 
The AHDR is padded to a maximum length with random bytes, and 
its length remains constant as it traverses the network (see Algo- 
rithmO. The FSes contained in the AHDR are onion encrypted, as 
is the padding added at each hop. Thus, it is not possible to dis¬ 
tinguish the initial random padding from the encrypted FSes, and 
neither of these from encrypted padding added by the nodes. 

Timing for position identification. A malicious node could try 
to learn its position on the path of a session by measuring timing 
delays between itself and the source (or the destination) of that ses¬ 
sion. HORNET offers two possible countermeasures. In the first, 
we assume that the malicious node wishes to measure the network 
delay between itself and the source. To perform such a measure¬ 
ment, the node must observe a packet directed to the source (i.e., 
on the backward path) and then observe a response packet from the 
source (on the forward path). However, HORNET can use asym¬ 
metric paths (32), making this attack impossible if the single node 
is not on both forward and backward paths. 

The second countermeasure is that, even if the node is on both 
paths, it is still non-trivial to discover that a specific forward flow 
corresponds to a certain backward flow, since the forwarding seg¬ 
ments for the two paths are independent. To link the forward and 
backward flows together the node would need to rely on the traffic 
patterns induced by the upper-layer protocols that are running on 
top of HORNET in that session. 

5.3 Active De-anonymization 

Session state modification. The state of each node is included in 
an encrypted FS. During the session setup, the FSes are inserted 
into the FS payload, which allows the source to check the integrity 

® A bandwidth-optimized alternative would be to allow two or three 
different payload sizes, at the cost of decreased anonymity. 


of these FSes during the setup phase. During data transmission, 
FSes are integrity-protected as well through per-hop MACs com¬ 
puted by the source. In this case, each MAC protecting an FS is 
computed using a key contained in that FS. This construction is se¬ 
cure because every FS is encrypted using a PRP keyed with a secret 
value known only to the node that created the FS: if the FS is modi¬ 
fied, the authentication key that the node obtains after decryption is 
a new pseudo-random key that the adversary cannot control. Thus, 
the probability of the adversary being able to forge a valid MAC is 
still negligible. 

Path modification. The two HORNET data structures that hold 
paths (i.e., FS payloads in the setup phase and AHDRs), use chained 
per-hop MACs to protect path integrity and thwart attacks like in¬ 
serting new nodes, changing the order of nodes, or splicing two 
paths. The source can check such chained per-hop MACs to de¬ 
tect the modifications in the FS payload before using the modified 
FS payload to construct AHDRs, and similarly intermediate nodes 
can detect modifications to AHDRs and drop the altered packets. 
These protections guarantee path information integrity as stated in 
Section|23] 

Replay attacks. Replaying packets can facilitate some types of 
confirmation attacks For example, an adversary can replay 

packets with a pre-selected pattern and have a colluding node iden¬ 
tify those packets downstream. HORNET offers replay protection 
through session expiration; replayed packets whose sessions have 
expired are immediately dropped. Replay of packets whose ses¬ 
sions are not yet expired is possible, but such malicious behavior 
can be detected by the end hosts. Storing counters at the end hosts 
and including them in the payload ensures that replays are recog¬ 
nizable. The risk of detection helps deter an adversary from using 
replays to conduct mass surveillance. Furthermore, volunteers can 
monitor the network, to detect malicious activity and potentially 
identify which nodes or group of nodes are likely to be misbehav¬ 
ing. Honest ASes could control their own nodes as part of an intru¬ 
sion detection system. 

5.4 Payload Protection 

Payload secrecy. Data packet payloads are wrapped into one layer 
of encryption using the key shared between the source and the des¬ 
tination, both for packets sent by the source on the forward and 
for packets sent by the destination on the backward path (see Sec¬ 
tion |4A4]l- Assuming that the cryptographic primitives used are 
secure, the confidentiality of the payload is guaranteed as long as 
the destination is honest. In Section|73]we discuss the guarantees 
for perfect forward secrecy for the data payload. 

Payload tagging or tampering. HORNET does not use per-hop 
MACs on the payload of data packets for efficiency and because the 
destination would not be able to create such MACs for the packets 
it sends (since the session keys of the nodes are known only to the 
source). The lack of integrity protection allows an adversary to tag 
payloads. Admittedly, the use of tagging, especially in conjunction 
with replay attacks, allows the adversary to improve the effective¬ 
ness of confirmation attacks. However, end-to-end MACs protect 
the integrity of the data, making such attacks (at a large scale) de¬ 
tectable by the end hosts. 

5.5 Denial-of-Service (DoS) Resilience 

Computational DoS. The use of asymmetric cryptography in the 
setup phase makes HORNET vulnerable to computational DoS at¬ 
tacks, where adversaries can attempt to deplete a victim node’s 
computation capability by initiating a large number of sessions 
through this node. To mitigate this attack, HORNET nodes can 
require each client that initiates a session to solve a cryptographic 
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puzzle m to defend against attackers with limited computation 
power. Alternatively, ISPs offering HORNET as a service can se¬ 
lectively allow connections from customers paying for the anonym¬ 
ity service. 

State-based DoS. HORNET is not vulnerable to attacks where ad¬ 
versaries maintain a large number of active sessions through a vic¬ 
tim node. One of HORNET’S key features is that all state is carried 
within packets, thus no per-session memory is required on nodes or 
rendezvous points. 

5.6 Topology-based Analysis 

Unlike onion routing protocols that use global re-routing through 
overlay networks (e.g., Tor (26l and I2P (50)), HORNET uses short 
paths created by the underlying network architecture to reduce la¬ 
tency, and is therefore bound by the network’s physical intercon¬ 
nection and ISP relationships. This is an unavoidable constraint for 
onion routing protocols built into the network layer (33] 113. Thus, 
knowledge of the network topology enables an adversary to reduce 
the number of possible sources (and destinations) of a flow by only 
looking at the previous (and next) hop of that flow. For example, 
in Figure [3(^ assume that ASO is controlled by a passive adver¬ 
sary. The topology indicates that any packet received from ASl 
must have originated from a source located at one of {ASl, AS2, 
AS3, AS4, AS5}. 

We evaluate the information leakage due to the above topology 
constraints in the scenario where a single AS is compromised. We 
derive AS-level paths from iPlane trace-route data (Tj, and use AS- 
level topology data from CAIDA OH. For each AS on each path 
we assume that the AS is compromised and receives packets from a 
victim end host through that path. We compute the end host’s ano¬ 
nymity set size learned by the adversary according to the topology. 
For instance, in Figure [3(^ if ASO is compromised and receives 
from AS 1 packets originally sent by a user in AS4, we compute the 
size of the anonymity set composed of all the ASes that can estab¬ 
lish valley-free paths traversing the link from ASl to ASO. In this 
example, the anonymity set size would be the sum of the sizes of 
ASl, AS2, AS3, AS4, and AS5. 

Similar to Hsiao et al. 1331 , we use the number of IPv4 addresses 
to estimate the size of each AS. Figure [3(b)| plots the CDF of the 
anonymity set size for different distances (in number of AS hops) 
between the adversary and the victim end host. For adversarial 

o 1 

ASes that are 4 hops away, the anonymity set size is larger than 2 
in 80% of the cases. Note that the maximum anonymity set size is 
2^^ in our analysis, because we consider only IPv4 addresses. 

Implications of path knowledge. Knowledge about the path, in¬ 
cluding the total length of the path and an adversarial node’s po¬ 
sition on the path, significantly downgrades the anonymity of end 
hosts. Considering again Figure [3(a)l if the adversary controlling 
ASO sees a packet incoming from ASl and knows that it is 4 hops 
away from the source host, he learns that the source host is in AS4. 
Compared with the previous case, we see that the anonymity set 
size is strongly reduced. 

We quantify additional information leakage in the same setting 
as the previous evaluation. Figure [3(^ represents the CDFs of the 
anonymity set sizes of end hosts according to the distance to the 
compromised AS. The anonymity set sizes are below 2^® in 90% 
of the cases when the adversarial ASes are 4 hops away, with an 
average size of 2^^. This average size decreases to 2^^ for the 
cases where the adversarial ASes are 7 hops away from the target 
hosts. 

Previous path-based anonymity systems designed for the net¬ 
work layer either fail to hide knowledge about the path 1451 or only 
partially obscure the information )33l . In comparison, HORNET 


protects both the path length and the position of each node on the 
path, which significantly increases the anonymity-set size. 

6. EVALUATION 

We implemented the HORNET router logic in an Intel soft¬ 
ware router using the Data Plane Development Kit (DPDK) 0 . 
To our knowledge, no other anonymity protocols have been im¬ 
plemented in a router SDK. We also implemented the HORNET 
client in Python. Eurthermore, we assembled a custom crypto 
library based on the Intel AESNI cryptographic library 0. the 
curve25519-donna library (4), and the PolarSSL libraries (3. We 
use IP forwarding in DPDK as our performance baseline. Eor com¬ 
parison, we implemented the data forwarding logic from Sphinx, 
LAP, Dovetail, and Tor using DPDK and our cryptographic library. 

Fairly comparing the performance of anonymity systems at the 
application layer with those that operate at the network layer is 
challenging. To avoid penalizing Tor with additional propagation 
delay caused by longer paths and processing delay from the kernel’s 
network stack, we implemented Tor at the network layer (as sug¬ 
gested by Liu et al. (D). Tor’s design requires relay nodes to per¬ 
form SSL/TLS and transport control. SSL/TLS between neighbor¬ 
ing relays at the application layer maps to link encryption between 
neighboring nodes at the network layer, which we consider orthog¬ 
onal but complementary to HORNET (see Section lT^ . Hence, for 
fair comparison, we implemented the network-layer Tor without 
SSL/TLS or transport control logic. Throughout our evaluation we 
refer to this implementation of Tor as L3 Tor. 

Our testbed contains an Intel software router connected to a 
Spirent TestCenter packet generator and analyzer m. The soft¬ 
ware router runs DPDK 1.7.1 and is equipped with an Intel Xeon 
E5-2680 processor (2.70 GHz, 2 sockets, 16 logical cores/socket), 
64 GB DRAM, and 3 Intel 82599ES 40 Gb/s network cards (each 
with 4 10 Gb/s ports). We configured DPDK to use 2 receiving 
queues for each port with 1 adjacent logical core per queue. 

6.1 Data Forwarding Performance 

Forwarding latency. We measure the CPU cycles consumed to 
forward a data packet in all schemes. Pigure|4] shows the average 
latency (with error bars) to process and forward a single data packet 
in all schemes (except SphinjQ) when payload sizes vary. We ob¬ 
serve that HORNET, even with onion encryption/decryption over 
the entire payload and extensive header manipulation, is only 5% 
slower than LAP and Dovetail for small payloads (64 bytes). Eor 
large payloads (1200 byte|3), HORNET is 71% slower (about 400 
nanoseconds slower per packet when using a single core) than LAP 
and Dovetail. However, the additional processing overhead enables 
stronger security guarantees. 

Header overhead. As a result of carrying anonymous session state 
(specifically cryptographic keys) within packet headers, HORNET 
headers are larger than Sphinx, L3 Tor, LAP, and Dovetail headers 
(see Table [2)- While larger headers reduce net throughput (i.e., 
goodput), this tradeoff appears acceptable: compared to L3 Tor, 
no state is required at relay nodes, enabling scalability; compared 
to Sphinx, data processing speed is higher; compared to LAP and 
Dovetail, HORNET provides stronger security properties. 

^We omit Sphinx from the comparison for better readability. In 
our experiments, processing a Sphinx packet takes more than 640K 
cycles due to asymmetric cryptographic operations. This is 3 or¬ 
ders of magnitude slower than that of HORNET, L3 Tor, LAP, and 
Dovetail. 

o 

Because LAP, Dovetail, and HORNET all have large packet head¬ 
ers of 300-1- bytes, we limit the largest payload in our experiments 
to be 1200 bytes. 
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(a) 



(b) Without path knowledge 



(c) With path knowledge 


Figure 3: a) An example AS-level topology with an adversarial AS (ASO). b) CDF of anonymity-set size when a position-agnostic AS 
on path is adversarial. “Hops” Indicates the number of ASes between the adversarial AS and the victim end host. For example, the 
point (25, 0.4) on the line “3 hops” means that the anonymity set size is smaller than 2^^ in 40% of cases when the end host is 3 hops 
away from the adversarial AS. c) CDF of anonymity-set size when an adversarial AS knows its own position on the path. For Figures 
b) and c), the maximum size of an end host’s anonymity set is 2^^ because we consider the IPv4 address space. Therefore, the ideal 
case for an end host is that the anonymity set size is 2^^ with probability equal to 1. 


Scheme 

Header Length 

Sample Length (Bytes) 

LAP 

12 -f 2s • r 

236 

Dovetail 

12 + s - r 

124 

Sphinx 

32-f (2r-f 2)s 

296 

Tor 

3+11-r 

80 

HORNET 

8 -1- 3r • s 

344 


Table 2: Comparison between the length of different packet 
header formats in bytes, s is the length of symmetric elements 
and r is the maximum AS path length. For the sample length, 
we select s = 16 Bytes and r — 7. Analysis of iPlane paths shows 
that more than 99% of all paths have fewer than 7 AS hops. 
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Figure |5(a)| and Figure |5(b)| demonstrate the goodput of all 
schemes (except SphinjQ) on a 10 Gb/s link when varying the num¬ 
ber of hops r, with 40-byte and 1024-byte payloads, respectively. 
Larger r means larger header sizes, which reduces the resulting 
goodput. 

When the payload size is small, the goodput of all protocols re¬ 
mains stable. This is due to the fact that no scheme can saturate 
the link, and accordingly the goodput differences between the three 
schemes mainly reflect the different processing latencies among 
them. Consequently, L3 Tor’s and HORNET’S goodput is 32% less 
than that of LAP and Dovetail. On the other hand, when the pay- 
load size is large, all schemes except Sphinx can saturate the 10 
Gb/s link. HORNET can reach 87% of LAP’S goodput while pro¬ 
viding stronger security guarantees. 


6.2 Max Throughput on a Single Router 

To investigate how our implementation scales with respect to the 
number of CPU cores, we use all 12 ports on the software router, 
generating HORNET data packets at 10 Gb/s on each port. Each 
packet contains a 7 AS-hop header and a payload of 512 bytes, and 
is distributed uniformly among the working ports. We monitor the 
aggregate throughput on the software router. 

The maximal aggregate throughput of HORNET forwarding in 
our software router is 93.5 Gb/s, which is comparable to today’s 
switching capacity of a commercial edge router |2- When the num¬ 
ber of cores ranges from 1 to 4, our HORNET implementation can 
achieve full line rate (i.e., 10 Gb/s per port). As the number of 
cores increases to 5 and above, each additional port adds an extra 
6.8Gb/s. 


Figure 4: Per-node data forwarding latency on a 10 Gbps link. 
Lower is better. 


Goodput. We further compare all the schemes by goodput, which 
excludes the header overhead from total throughput. Goodput is a 
comprehensive metric to evaluate both the packet processing speed 
and protocol overhead. For example, a scheme where headers take 
up a large proportion of packets yields only low goodput. On the 
other hand, a scheme with low processing speed also results in poor 
goodput. 


6.3 Session Setup Performance 

We evaluate the latency introduced by processing setup packets 
on each border router. Similar to measuring the latency of data for¬ 
warding, we also instrument the code to measure CPU cycles con¬ 
sumed to process packets in the session setup phase. Table [3 lists 
the average per-node latency for processing the two setup packets 
in hornet’s session setup phase. Due to a Diffie-Hellman key 

^Sphinx’s goodput is less than 10 Mb/s in both cases because of 
its large packet headers and asymmetric cryptography for packet 
processing. 
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Figure 5: a) Data forwarding goodput on a 10 Gbps link for small packets (40 Byte payloads); b) Data forwarding goodput large 
packets (1024 Byte payloads). Higher is better. 


exchange, processing the two setup packets in the session setup 
phase increases processing latency (by about 240/is) compared to 
data packet processing. However, HORNET must only incur this 
latency once per session. 


Packet 

Latency (K cycles) 

Latency (/rs) 

PO 

661.95 ± 30.35 

245.17 ±11.24 

P© 

655.85 ± 34.03 

242.91 ± 12.60 


Table 3: Per-node latency to process session setup packets with 
standard errors. 

6.4 Network Evaluation 

Distribution of AS-level path length. The bandwidth overhead of 
a HORNET packet depends on the number of ASes traversed by the 
packet. Figure[^demonstrates the CDF of AS-level path lengths of 
the paths extracted from our data source. We observe that 99% of 
the paths have a path length smaller than 7, and the mean AS-level 
path length is 4.2. Thus, to achieve 128 bits of security, 48 bytes 
per AS hop are required, leading to an average overhead of 201.6 
bytes. 

Non-scalability of a stateful design. 

We evaluate the memory capacity needed to maintain state re¬ 
quired by a stateful design to support Internet-scale anonymous 
communication. We consider the design of Tor, one of the most 
popular onion routing systems today CSl, and assume that each 
Tor node {onion router or OR) would correspond to an autonomous 
system (AS), as proposed by Liu et al. 1361 . Analyzing the CAIDA 
Internet Traces (T), we found that a 10 GbE backbone link handles 
about IM new flows every minute under normal operating condi¬ 
tions. Since the largest inter-AS links today have up to ten times 
that capacity (100 GbpsJ3 this means that at the core of the net¬ 
work there are edge routers of ASes that handle about lOM new 
flows per minute. 

If we assume that half of these flows would use a Tor circuit, be¬ 
cause of the default lifetime of circuits of 10 minutest^ we obtain 

'^E.g., see www.seattleix.net/participants.htm. 

" We measure the number of flows taking this lifetime into account, 
in particular we expire flows only if no packets where seen on them 



Figure 6: CDF of AS-level path length. 


that ORs on such edge routers would need to store state for approx- 
imatively 50M circuits at any given time. Since Tor stores at least 
376 bytes per circuit, this translates to almost 20 GB of memory. 
This might still be acceptable for high-end devices, but there are 
a number of additional factors that make keeping state unfeasible, 
even for ASes handling less traffic: 

• The growing number of users on the Internet and the increas¬ 
ing number of devices per user result in an increasing number 
of traffic flows; 

• The state for each circuit would actually be larger, as for ac¬ 
tive circuits the ORs need to store the packets being trans¬ 
mitted until they are acknowledged by the next hop; 

• A DDoS attack could force an OR to store much more state 
by opening a large number of new circuits through that OR. 


7. DISCUSSION 

for over 10 minutes. Also note that in our setting it would not be 
possible to have multiple streams per circuit, unless the destinations 
of those streams are all within the same AS. 
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7.1 Retrieving Paths Anonymously in FIAs 

HORNET assumes that the source can obtain a forward path and 
a backward path to an intended destination anonymously in FIAs. 
We briefly discuss how a source host using HORNET can retrieve 
two such paths in NIRA, SCION and Pathlets. 

SCION hosts rely on path servers to retrieve paths. In SCION, 
each destination node registers on a central server its “half” path: 
the path to/from the network “core”. To compose full paths (for¬ 
ward and backward paths) between a source and a destination, the 
source only needs to anonymously fetch the destination’s half paths 
from/to the network core and combine them with its own half paths. 

To anonymously retrieve a destination’s half paths, the source 
can use one of the following two methods. As a first method, the 
source can obtain the path to/from a path server through an unpro¬ 
tected query using other schemes, from resolver configuration, or 
from local services similar to DHCR The source then establishes 
an anonymous HORNET session to the server. Once a HORNET 
session is created, the source can proceed to anonymously request 
half paths of the destination. Though it is possible to reuse the 
established HORNET session to a path server to query multiple 
paths (for different destinations) for better efficiency, using a sepa¬ 
rate session to retrieve each path is more secure because it prevents 
profiling attacks. 

Alternatively, the source can leverage a private information re¬ 
trieval (PIR) scheme (211 to retrieve the path anonymously from 
the path server, so that the path server cannot distinguish which 
destination the source connects to. However, a PIR scheme will 
inevitably add bandwidth and computational overhead to both the 
source and the path server, increasing session setup phase la¬ 
tency (38). 

In NIRA and Pathlets, the situation is different because rout¬ 
ing information (i.e., inter-domain addresses and route segments, 
and pathlets, respectively) is disseminated to users. The source can 
therefore keep a database local path database, querying it (locally) 
on demand. 

7.2 Integrating witii Security Meciianisms 
at Different Layers 

At the network layer, HORNET can benefit from ASes that of¬ 
fer traffic redirection to mitigate topology-based attacks (see Sec¬ 
tion 122). For instance, ASes can allow paths that deviate from 
the valley-freeness policy to increase the anonymity set size of end 
hosts. This enables a trade-off between path length and anonymity, 
as described by Sankey and Wright (45). 

In addition, upper-layer anonymity protocols can be used in con¬ 
junction with HORNET to provide stronger anonymity guarantees. 
For example, to entirely remove the concerns of topology-based at¬ 
tacks, a single-hop proxy or virtual private network (VPN) could be 
used to increase the size of the anonymity sets of end hosts. Similar 
solutions could also protect against upper-layer de-anonymization 
attacks, in particular fingerprinting attacks on the transport proto¬ 
col (47). 

At lower layers, HORNET is also compatible with link-layer 
protection such as link-level encryption. The role of link-level en¬ 
cryption in HORNET is comparable to SSL/TLS in Tor. Link en¬ 
cryption prevents an adversary eavesdropping on a link from being 
able to distinguish individual sessions from each other, therefore 
making confirmation attacks much harder for this type of adver¬ 
sary. 

7.3 Limitations 

Targeted confirmation attacks. When for a certain session an 
adversary controls both the node closest to the source and the node 


closest to the destination (or the destination itself), it can launch 
confirmation attacks by analyzing flow dynamics.These attacks can 
be made more effective by replaying packets. 

HORNET, like other low-latency onion routing schemes 1261 . 
cannot prevent such confirmation attacks targeting a small number 
of specific users (461 [HI. However, HORNET raises the bar of 
deploying such attacks at scale: the adversary must be capable of 
controlling a significant percentage of ISPs often residing in multi¬ 
ple geopolitical areas. In addition, the packet obfuscation measures 
built into HORNET (discussed in Section |5j make it non-trivial 
to link two flows, since it is not possible to simply match packets 
through bit patterns. Timing intervals for packet sequences need 
to be stored and compared, thus performing such operations for a 
large fraction of the observed flows is expensive. Furthermore, it 
is difficult for attackers to perform active attacks (e.g., packet re¬ 
play) at scale while remaining undetected. For instance, a down¬ 
stream benign AS can detect replayed packets by a compromised 
upstream AS; end hosts can also detect and report packet tagging 
attacks when (a threshold number of) end-to-end MACs do not suc¬ 
cessfully verify. 

Perfect forward secrecy. A drawback of HORNET’S efficiency- 
driven design is that it does not provide perfect forward secrecy for 
the link between communicating parties. This means that an adver¬ 
sary could record the observed traffic (the setup phases, in partic¬ 
ular), and if it later compromises a node, it learns which node was 
next on the path for each recorded session. This is an unavoidable 
limitation of having a setup that consists of a single round-trip. 

Other systems (e.g.. Tor) use a telescopic seturF^ which achieves 
perfect forward secrecy at the cost of diminished performance (in 
particular higher latency, and also an additional asymmetric crypto¬ 
graphic operation per node). Using a telescopic setup is also possi¬ 
ble for HORNET, but in addition to the performance cost it also re¬ 
quires that all paths be reversible. However, this requirement does 
not hold in today’s Internet, where a significant fraction of AS-level 
paths are asymmetric 1321 . 

It is important to note that in HORNET it is still possible to 
achieve perfect forward secrecy for the contents of the communica¬ 
tion, i.e., for the data exchanged between sources and destinations. 
The destination needs to generate an ephemeral Diffie-Hellman key 
pair, and derive an additional shared key from itQ Destinations 
also need to generate a new local secret SV frequently, so in the 
event of a destination being compromised it is not possible for the 
adversary to decrypt FSes used in expired sessions. 

8. RELATED WORK 

Anonymity systems as overlays. The study of anonymous com¬ 
munication began with Chaum’s proposal for mix networks 1201 . 
A number of message-based mix systems have been proposed and 
deployed since (3n[^l22l[2^. These systems can withstand an 
active adversary and a large fraction of compromised relays, but 
rely on expensive asymmetric primitives, and message batching 
and mixing. Thus, they suffer from large computational overhead 
and high latency. 

Onion routing systems diiisiiiiiiigi were proposed to effi¬ 
ciently support interactive traffic. In general, low-latency onion 

^^In the telescopic setup, a source iteratively sets up a shared key 
with each AS: the source sets up a shared key with the first-hop 
AS; the source sets up a shared key with the nth-hop AS through 
the channel through Ist-hop AS to (n — l)th-hop AS. 

*^This feature, though omitted in Section|4]for simplicity, is part of 
our implementation. It is done in such a way that the forward se¬ 
cret shared key is included in the destination’s FS during the setup, 
without any additional packet being required. 
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routing systems are vulnerable to end-to-end confirmation at¬ 
tacks f35l . and may fail to provide relationship anonymity when 
two routers on the path are compromised I30II34I . HORNET shares 
these limitations. 

One specific onion routing system, Tor, has a number of security 
advantages over HORNET. Tor can prevent replays and has perfect 
forward secrecy for its sessions. Additionally, due to its overlay 
design which uses global redirection. Tor is not constrained by the 
underlying network topology. However, global redirection enables 
the attack vector that allows even single compromised ASes to per¬ 
form confirmation attacks I41II14I . as one AS can be traversed mul¬ 
tiple times. This attack is not possible in HORNET since packets 
traverse each AS on the path only once. 

In addition, HORNET’S performance also distinguishes it from 
all existing schemes based on overlay networks: first, HORNET 
can directly use short paths provided by underlying network ar¬ 
chitectures, reducing propagation latency; second, HORNET re¬ 
quires only a single round trip to establish a session, reducing the 
setup delay; third, HORNET eliminates the processing and queu¬ 
ing delays both on relay nodes and in the kernel’s network stack; 
finally, edge routers in HORNET offer higher throughput compared 
to voluntarily-contributed end hosts, increasing the total throughput 
of anonymous traffic. 

Anonymity systems in FIAs. Hsiao et al. explored the de¬ 
sign space of efficient anonymous systems with a relaxed adversary 
model. In their scheme, LAP, the adversary can compromise only 
a single node, and the first hop must always be honest. Sankey 
and Wright proposed Dovetail l45l (based on Pathlets and 
SCION (521 [ni) which has the same attacker model as LAP, ex¬ 
cept it allows the first hop to be compromised. Moreover, neither 
LAP nor Dovetail can support asymmetric paths where packets tra¬ 
verse different sets of nodes in different directions. HORNET of¬ 
fers three improvements over LAP and Dovetail: 1) HORNET fully 
hides path information, i.e., total path length and nodes’ positions, 
in packet headers; 2) HORNET protects and obfuscates packet con¬ 
tents by onion-encryption/decryption, thwarting correlating pack¬ 
ets of the same flow by selectors; 3) HORNET supports asymmet¬ 
ric paths and allows the first hop ASes to be compromised. Though 
HORNET introduces additional overhead in comparison with LAP 
and Dovetail, our evaluation results show that HORNET can still 
support high-speed packet forwarding at nearly 80% of line rate. 

The research community has also explored applying onion rout¬ 
ing to FIAs. Liu et al. 1361 proposed Tor instead of IP as an FIA 
that regards anonymity as the principal requirement for the network 
architecture. However, details on how to scale Tor’s current design 
(requiring per-circuit state) to Internet scale were not addressed. 

DiBenedetto et al. (25) proposed ANDaNA, to enable onion rout¬ 
ing in Named Data Networking (NDN) dD. NDN focuses on con¬ 
tent delivery and thus inherently different from the FIAs we con¬ 
sidered. 

9. CONCLUSION 

In this paper, we address the question of “what minimal mecha¬ 
nism can we use to frustrate pervasive surveillance?” and study the 
design of a high-speed anonymity system supported by the network 
architecture. We propose HORNET, a scalable and high-speed 
onion routing scheme for future Internet architectures. HORNET 
nodes can process anonymous traffic at over 93 Gb/s and require 
no per-flow state, paving the path for Internet-scale anonymity. Our 
experiments show that small trade-offs in packet header size greatly 
benefit security, while retaining high performance. 
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